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SYSTEM AND METHOD FOR fflERARCHICAL LAYOUT SPECIALIZATION 
Background 

[0001] The present invention relates to pages in general and more specifically to 
documents of text processing systems, Portal Pages, Web pages, or any other type of 
pages which is common that they have having a certain layout which that may be 
specialized by others, and in particular a system and method which allows provides the 
ability to create, retrieve, specify, and manipulate that layout in a hierarchical manner. 

[0002] Without restricting the scope of the present invention to Portal Pages only^ the 
present invention will be discussed with respect to Portal Pages as a preferred 
embodiment of the present invention. 

Backgrpynd pf thg Rglatgd Art 

[0003] Portals are becoming the focal points for users to access information (content) and 
appKcations fi-om many different sources. Typically, Portals get information from local or 
remote data sources, e.g. from databases, transaction systems, syndicated Content- 
Providers, or remote Web Sites, and render and aggregate this information into complex 
pages to provide information to users in a condensed form. In addition to pure 
information, many Portals also include applications like e-mail, calendar, organizers, 
banking, bill presentment, etc. A well-known example is the Yahoo! Portal that provides 
access to a large amount of content and applications. 

[0004] Different rendering and selection mechanisms are required for different kinds of 
information or applications, but all of them rely on the portal's infrastructure and operate 
on data or resources that are owned by the portal, e.g. user profile information, persistent 
storage or access to managed content. Consequently, most of today's Portal 
implementations provide a component model, where pluggable portal components 
modules referred to as Portlets can be added to the portal infrastructure. Portlets are 
pluggable components that can be added to Portals and are designed to run inside a 
portal's portlet container which provides a common interface to all executable portlets. 
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Portlets may provide different fiinctions ranging fi-om simple rendering of static or 
dynamic content to application functions such as e-mail, calendar, etc. Portlets are 
invoked indirectly via the portal application and produce content that is suited for 
aggregation in larger Web pages, e.g. portlets should produce mark-up fragments 
adhering guidelines that assure that the content generated by different portlets can be 
aggregated into one Web page. 

[0005] Each Portal Page has a specific layout. Layout means that each Portal Page may 
be divided in one or more areas (rows, columns) Those areas are called containers. Each 
container may be subdivided into one or more sub-containers or may include one or more 
frames which display a defined type of content rendered by portlets. The sub- 
container[[s]] may be fiirther divided into another sub-container and so on. 

[0006] More and more globa lly playing companies want[[s]] to set up an Intranet Web 
Site for its employees. Each employee should have access to a variety of sources, 
including global, regional, and country-spccific-content. Ideally each level of sources, 
e.g. global, regional, or country-specific, should have its own administrator for managing 
the area specific content accessible by the employees without allowing the administrator 
to delete content of the next higher level of source totally. 

[0007] The prior art provides two approaches to that problem: 

[0008] The top-level administrator of the Portal Page knows in advance which area 
specific content should be made available to whom. The administrator then places all 
content on the Portal Page, and uses a filtering technique to tailor the Portal Page to an 
individual employee at runtime. This is in essence the approach described by WO 
0075840 A2 "Method for deducing level of interest in information structures via 
annotations". A disadvantage of that approach is that a centralized administration is 
required in order to determine the content to be provided to the employee. The central 
administration needs stead[[il]]y input from the regional and country organizations units 
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regarding which content should be made available to the employees. This is time 
consuming and costly. 

[0009] Another approach is that the content is split and distributed across several Portal 
Pages. Each level of administrators, e.g. responsible for global, regional, or country- 
specific content, constructs its own Portal Page that contains links to the other Portal 
Pages. A disadvantage of that approach is that the content structure needs to be navigated. 
Furthermore, there is no "view at a glance". 

Summary of the Invention 

[0010] It is therefore object of the The present invention [[to]] provides a new system and 
method for providing layout specialization of pages considering hierarchical 
administration and content requirements howeve r ^ yet avoiding disadvantages of the prior 
art approaches. 

[00 1 1 ] This object is solved by the features of the independent claims. 

[0012] — Further preferred embodiments of the present invention are laid down in thc - 
dcpcndcnt claims. 

[0011] The present invention discloses a system and method for delegated page 
specialization based on a page layer concept. A page consists of a set of layers. Except 
the first layer, each layer represents a delta (container, frames) in its layout to its previous 
layer introduced on the corresponding level of administration. Administrators can modify 
the previous layers by defining new immutable and optional containers or fi-ames on the 
page (deltas). Only the deltas to the previous layers are stored with assignments to their 
parent layers. Immutable containers or fi-ames of previous layers cannot be modified. The 
final page is automatically constructed as a[[n]] union of deltas being stored in a so called 
tree-structure. The delegated page specialization is preferably accomplished via a GUI- 
component which supports the administrators. 
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Brief Description of the Drawings 

[0012] The present invention will be described in more detail with the accompanying 
drawings in which 

[0013] FIG. 1 shows a typical Portal Page with several fi-ames, 
[0014] FIG. 2 shows the basic method of the present invention, 
[0015] FIG. 3 shows the inventive page layer concept, 

[0016] FIG. 4A/B shows a preferred embodiment of the internal representation of the 
components (container) based on a three-layer structure, 

[0017] FIG. 5 A shows a prior art portal, and FIG. 5B shows that portal with the inventive 
modules, 

[0018] FIG. 6 shows a preferred embodiment of a GUI for administrators, 

[0019] FIG. 7 shows a flow chart for the delegated page specialization by the different 
administration level as used by the present invention, and 

[0020] FIG. 8 shows a flow chart for construction of a page according to the present 
invention. 

Detailed Description 

[0021] A typical Portal Page consists of several fi-ames 1-6. Each frame represents a 
place holder for content provided by a defined portlet. Containers 8 (dotted line) as 
defined in that application have no assigned portlets. They offer the possibility to create 
fiirther sub-containers or to include frames. 

[0022] A very important aspect of the present invention is that the fixnctionality to create. 
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modify, delete or move containers or fi-ames is distributed across several administration 
levels as shown in FIG. 2. The administrator of the highest level (Portal Administrator) 
creates a layer which may comprise one or more containers or fi-ames and grants edit 
rights to a group of administrators of the next administration level. This may be done for 
each page (PI, P2, . . . Pn). The next administration level (Group Administrator/Sub- 
Group Administrator) can specialize that page by adding or removing containers/frames 
which have not been fixed by the Portal Administrator. 

[0023] FIG. 3 shows the inventive page layer concept. 

[0024] For the implementation of the delegated page specialization a new page concept 
was introduced. A page consist of a set of layers 100,200,300. Except the first layer 
(basic layer, 100) each layer represents a delta (container, fi-ames~derived layer) to its 
previous layer introduced on the corresponding level of administration. Administrators 
can modify the previous layer by defining new immutable and optional containers or 
frames on the page (delegated specialization). Only the deltas to the previous layer are 
stored with assignments (e.g. identifier) to their parent layer. Immutable containers or 
frames of previous layers cannot be modified. The final page is automatically constructed 
as a[[n]] union of deltas being stored in a so called tree-structure. So, derived layers can 
be represented as a tree structure with a basic layer created by a highest administration 
level in the root, and administration/user defined page fi-agments as leafs. FIG. 3 
illustrates the delegated page specialization principle with 3 specialization layers 100, 
200, 300. The Administrator on the highest level creates a basic layer 100 with 2 rows 
110,120. The first row 110 is immutable(F) and includes 3 immutable frames 111-113 
with portlets PI, P2 and P3. The second row is partly immutable and consists of 3 
columns 121,122,123. The first column 121 is immutable and includes 3 fi-ames: 2 frames 
with portlets P4 and P5 are immutable; the frame with portlet P6 is optional. The second 
column 122 and the third column 123 are optional. The second column 122 consists of 3 
optional frames with portlets P7, P8 and P9. The third column 123 (container) is empty. 
This means that the following changes are permitted/prohibited on the next layers 
200,300. The first row 110 cannot be changed at all because everything is immutable. In 
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the second column 121 nothing can be added/deleted (the column is immutable), i.e. the 
number of columns cannot be changed. In the first column 121 only the last portlet (P6) 
can be replaced by another portlet. Nothing can be deleted. In the second column 122 and 
in the third column 123 all fi-ames can be deleted, any containers/fi-ame can be added. On 
the second level 200 one of the administrators has replaced the portlet P6 with the portlet 
P12 in the first column 120, removes the portlet P9 (with frame) from the second column 
122 and makes this column immutable (f). Administrator/user on the next level 300 has 
replaced portlet P12 by portlet 10 in the first column 121, replaced portlets P7, P8 by 
P21,P15 in the second column 122 and added P17 and P20 to the third column. Nothing 
can be added/deleted from the second column 122. 

[0025] For the internal representation an overall page is constructed as a union of data 
store page layers. For this purpose the page instances for all layers previous to the layer, 
managed by the user whose pages are displayed, are loaded. Then all containers or frames 
belonging to these layers are loaded into the page and connected according to their 
parent/replacement relationships. The pointer to the free root is set. This structure is 
flexible, allows fast tree traversing operation and provides enough information to save the 
structure back to several page instance elements. FIG. 4A, B illustrates a sample an 
example of how a three-layer page instance structure (PIl, PI2, PI3) can be franslated into 
an internal page representation. Each component (container or frame) either has a parent 
ID or a replacement ID. Furthermore each component has an assigned layer ID (not 
shown). The ordinal gives information about a position of a component in the children 
list of the parent component. The component with neither parent nor replacement is 
defined as a root component (FIG. 4B). 

[0026] For example the first page instance PIl (basic layout—first layer) defines 1-10 
components, the second page instance PI2 (second layer) defines fiirther components 21 
to 27, and finally the third page instance PI3 (third layer) defines fiirther components 40 
and 41 (FIG. 4A). The internal representation scheme shows the parent/replacement 
relationship of the components (FIG. 4B). For example the components with the IDs 40 
and 41 replace the components with IDs 25 and 26. The parent component for component 
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40 is now component 24, and for component 41 is now 24 too. The component 24 itself 
replaces component 8. The parent component of component 24 is now component 3. The 
parent component of component 3 is component 1 which has no further parent or 
replacement components. FIG. 7 shows the inventive method for delegated 
specialization. The administrator of the highest administration level creates a new page 
with an ID, page title, and description 31. Then he defines a certain basic layout for that 
page which may comprise one or more containers with or without fi-ames with their own 
ID and assigned layer ID 32. Portlets are assigned (Portlet ID) to each defined frame 33. 
Then, the administrator defines which one of the defined containers or frames cannot be 
changed by the next administration level and grants access rights to the next 
administration level to specialize that page 34. The next administration level may 
specialize the page by replacing frames, adding new frames into the existing container or 
deleting existing frames/container or moving frames from one container into another one 
or creating sub-containers provided it is allowed and the administrator has the access 
rights 35. Each specialization (layer, container, frame) is identified by [[an]] their own ID 
(layer ID), and their associated parent ID. Finally the administrator may define parts of 
his performed specialization which cannot be changed and grants access rights to next 
administration level 36. The foregoing steps are repeated until the specialization is 
finished 37. A typical prior art Portal (FIG. 5 A) preferably comprises an authentication 
component 20 for giving access to the portal 1, a customization component 10 allowing 
configuration of the portal 1, an aggregation component 30 which finds out which portlet 
in which order should be displayed on the requested user page, an authorization 
component 40 for providing access only to those portlets 80, 90 for which the user is 
registered, and a portlet container component 60 which provides a common interface to 
all executable portlets stored locally 80 or remotely 90. The new and inventive part of the 
present invention mainly addresses the customization component (FIG. 5B). The new 
customization component 11, 13, 14, 16 will be internally divided into several 
components for working with different parts of the layout design. The Page Manager 1 1 
will be responsible for working with pages. Thej[[F]]ollowing actions will be a part of 
the Page Manager: create, rename, delete pages, set allowed mark up per page, change 
order, and manage access rights to pages. The pages created by the Page Manager 1 1 are 
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stored in a page data store 12. The pages will include page title, description, etc. Several 
page instances (e.g., all the layers of the same page) will reference the same page 
descriptor. This will allow defining a title once and using it for all speciaUzed pages. A 
page instance (layer) will correspond to one specialization layer and will reference only 
deltas (container or fi-ames) defined on this layer. Each container or frame belongs to 
exactly one page and references either its parent or replacement container or fi-ame. A 
r[[R]]eplacement container/frame is a container/frame in the parent layer, which was 
replaced during specialization by this container/fi-ame. 

[0027] The Portlet Browser 13 will display and navigate portlets. The f [[F]]ollowing 
actions are included: navigate available portlets, and search portlets. 

[0028] The Layout Manager 14 will support constructing page layouts of containers or 
frames and working with fixed/optional elements. This includes add/remove columns and 
rows, add portlets, mark as "immutable"/" editable", edit portlets, edit column/row 
properties. 

[0029] The data generated by the Layout Manager is are stored in a container data store 
15 as shown in FIG. 5B. The container data store 15 preferably stores the basic layout 
created by the highest administrator level in the first layer, and all deltas of each layer to 
its previous layer with their own ID as well as their parent layer ID. 

[0030] The Colors & Skins Manager 16 will provide support for dynamic definition of 
component visual representation: apply skin to page or individual portlets, and select 
coloring scheme for page. 

[0031] FIG. 6 illustrates an example GUI of the fiinctionality of the Page Manager, the 
Portlet Browser and the Layout Manager as it could be provided for the portal 

administrator. The following GUI elements are provided in the Page Manager: a list 
element to show the available page, buttons to create/rename/delete page, text Entry field 
for new pages or renaming them. The Page Manager preferably implements the story 

8 



Substitute Specification 



10/502,247 



"User creates page". Upon entering a new name, the user can select to create a new page 
by saving it. The new name does not have to be unique, but the for purpose of continued 
maintainability it is recommended to do so. A new page is initially empty. The user who 
created the new page has imphcitly assigned "manage" rights to that page. Another story 
may be "user renames a page". The user selects an existing page, types the new name and 
chooses to rename that page. To rename a page, the user must have "manage" rights to 
that page. A further story may be "user deletes page". The user selects an existing page, 
and chooses to delete that page. To delete a page, the user must have "manage" rights to 
that page. User selects markups (devices). The user selects an existing page, selects the 
markups (or devices) that the page can be rendered for. Another ftmctionality could be 
provided by a Page Chooser GUI which provides a Hst to show the available pages. The 
Page Chooser GUI may provide the story "user selects page for customization". The user 
selects an existing page, and chooses to view/edit that page. The layout manager shows 
the new page and prepares it for any allowed modification. The user is only presented 
with the pages that [[s/he]] he or she has "view" or "manage" rights for. Upon entering 
the customizer (i.e. the page that contains all or part of the components described in this 
document), the page chooser has the current page prc-sclcctcd. A further functionality 
may be provided by a Portlet Browser GUI which provides a list of elements to show the 
available portlets and a button to add portlets. The Portlet Browser may provide the story 
"user adds portlet to layout". The user selects a portlet fi-om the list of available portlets, 
and chooses to add to the current layout (see below) at a selected position. The portlet can 
only be added if its new parent is not marked as "immutable" or if parent belongs to a 
layer that the user has "manage" rights for. If the component that the portlet is added to is 
marked as "immutable" the portlet defauUs to being not "editable". A further functionality 
may be provided by a Layout Manager GUI which provides the "layout area", a list 
element to show the available layout components at the moment: rows and columns), 
buttons to add, move, and remove layout components, and a button to save the (modified) 
page. The layout manager implements the story "User adds layout component". The user 
selects a layout component from the list of available components, and chooses to add it to 
the page. The component can only be added if its new parent is not marked as 
"immutable" or if tiig parent belongs to a layer that the user has "manage" rights for. 
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Another story may be "User removes layout component". The user selects a layout 
component in the current layout, and chooses to remove it from the page. The selected 
component can only be added if its new parent is not marked as "immutable" or if parent 
belongs to a layer that the user has "manage" rights for. A further story may be "User 
moves layout component" The user selects a layout component in the current layout, and 
chooses to move it. The selected component can only be added if its new parent is not 
marked as "immutable" or if the parent belongs to a layer that the user has "manage" 
rights for. A fiirther story is "marks layout component as "immutable". The user selects a 
layout component in the current layout, and marks it as "immutable". As a side effect, all 
parent components will implicitly marked as "immutable" as well. The user can only 
change the current setting if s/he has "manage" rights for the layer that the respective 
component is part of Another story may be "user marks portlet as "editable". The user 
selects a portlet in the current layout, and marks it as "editable". This means that the users 
who have an "edit" right for the page and the "edit" right for the portlet will be able to 
edit the portlet. The portlet that [[arc]] is declared as "not editable" can be only edited by 
the administrator who has "manage" rights for the layer that the portlet is part of The 
user can only change the current setting if she/he has "manage" rights for the layer that 
the respective portlet is part of A further story may be "user edits portlet". The user 
selects a portlet, and chooses to edit that portlet. The user can only edit a portlet if she/he 
has either "manage" rights for the layer that portlet is part of or if she/he has "edit" rights 
and that portlet is marked as "editable". Finally, a fiirther story may be "User saves page". 
The user chooses to save the current page and its layout. If this is not the initial layer, it 
adds another layer to the existing one(s) that this page is based on. 

[0032] FIG. 8A/B shows the page aggregation according to the present invention. When 
the user of a portal makes a login 21 all pages ID are determined for which the user has 
access rights. Then a list of all pages instances is loaded 22 for which the user has access 
rights and a page list is displayed not showing derived layers instances 23. After selecting 
one page layer by layer all containers and frames belonging to the appropriate layer are 
loaded from the container data base 24. Then the container and frames are assembled 
layer by layer starting with upper most container of the first layer and connecting all 
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fiirther containers or fi^ames to their parent 25. Then proceed to the next layer 26, add the 
containers or fi-ames fi-om the next layer to the already assembled parts, replace 
containers or fi-ames by their shadows, add new children containers or fi-ames. 

[0033] Finall y, the method repeats previous steps for all layers 27. Then the method geta 
the list of portlets defined on that page and assigns the portlet IDs to the corresponding 
frame 28. Then the tree is traversed and the containers are rendered and the invoker is 
called to render the portlet content 29,30. 

[0034] The present invention may be summarized as follows: The key to the realization 
of the delegated page specialization as described in the previous section is to keep track 
of the hierarchy of page specializations. By doing so, the dependency between different 
specializations is maintained. At the same time, since page specialization allows the 
administration to be decentralized, it is possible for different people or administrators to 
specialize the page completely independently of each other. It is only at the time of 
visualization (i.e. the rendering of a Web Page or Portal Page) that the hierarchy of page 
specializations is constructed and aggregatietted to create a combined view of all page 
instances and its respective specializations. 

[0035] As already mentioned^ that this patent application is not limited to any particular 
content type. The content type may be Web Pages ((content elements: mark-up 
fragments), Portal Pages (content elements: portlets), text documents (content elements: 

chapter, paragraphs, pictures, etc.). 

[0036] By storing page specialization as content deltas and content elements (of possibly 
various tj^es), and loading and re-creating it in the aforesaid fashion, it is possible to 
specialize content in any number of ways (only limited by the type of content elements), 
specialize content in any number of times (only limited by memory and storage), "view at 
a glance" (no links or references to follow), decentralize knowledge about the document, 
assign permissions to each specialization so that fiirther specialization can be 
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administrated in a decentralized fashion (in a centralized document it is much harder—if 
not impossible—to have fine-grain control over authorization). 

[0037] Accordingly, it is possible to m [[M]]ake modifications to a specialization that has 
aheady been further specialized. 
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